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VIRTUAL PROCUREMENT FOLDER 



BACKGROUND OF THE INVENTION 

5 Field of the Invention 

The present invention relates to procurement processes. More 
particularly, the present invention relates to a virtual procurement folder 
which stores all of the records, decisions, quotes, and other procurement 
10 information generated during a procurement process. 

Description of the Related Art 

Procurement is the process of acquiring goods and services required to 
sustain an organization's activities. In the public sector, for example, the 

15 individuals involved in this process generally include government employees 
who act as buyers, vendors who act as sellers, procurement officers who act 
as facilitators, and citizens who act as observers. Each of these actors has 
four primary goals for the procurement process: that the process be timely, 
efficient, value-maximizing, and fair. 

20 Figure 1 shows the stages and sequential flow of a procurement 

process according to the prior art. As shown in Figure 1, the procurement 
process usually begins at requisition stage 5. A requisition is a document 
used by buyers within an organization to request that goods or services 
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identified in the requisition be purchased on their behalf by a procurement 
officer. The procurement officer solicits the marketplace to determine which 
vendor or vendors can supply the goods or services described in the 
requisition. 

5 Once one or more vendors are identified, the vendors are sent a 

solicitation document at solicitation stage 10, identifying the requirements for 
the goods or services supplied in the requisition document. The solicitation 
document invites the vendors to put a price on the goods or services. Or, 
alternately, the solicitation document invites the vendors to supply alternate 
10 substitute goods or services other than the ones described in the solicitation. 

The identified vendors then prepare bid responses to the solicitation at 
bid response stage 15. Bid responses generally contain information such as a 
vendor's proposed price and the time to delivery of the items listed in the 
solicitation. 

15 The procurement officer next evaluates all of the bid responses sent by 

the vendors at evaluation stage 20. The procurement officer generally scores 
each vendor based upon any number of pre-selected criteria, and selects a 
vendor to supply the requested goods or services. 

The procurement officer, acting as an agent of the organization, 

20 awards the determined vendor a contractual document known an award at 
award stage 25. The award sets out the price of the requested goods or 
services. The award further details the legal obligations of the organization, 
acting as a buyer of the requested goods or services, and details the legal 
obligations of the selected vendor, acting as a seller of the requested goods or 

25 services. 

After the award contract has been signed by the organization and the 
selected vendor, the vendor delivers the now contracted- for goods or services 
to the organization. When the organization receives goods, the organization 
makes a recording as to what is being received from the vendor, and 

30 optionally, the organization may inspect the delivered goods. Next, the 

awarded contracting vendor is paid. Safeguards are usually in place which 
make sure the vendor is authorized to be paid. 
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At contract management stage 30 of the procurement process, the 
progress of the execution of the award contract is carried out by the 
management of the many different documents associated with the execution 
of the award contract. 

5 Existing procurement solutions to the above-described procurement 

process are neither timely nor efficient. For instance, current existing 
procurement solutions include manual paper based processes whereby each 
stage of the procurement process has different paper forms, and a lot of time 
is spent copying similar data between the forms, such as manually copying 
10 item procurement specifications from the requisition document to the 
solicitation document. Further, much time is wasted tracking where data 
originated from, what stage a procurement is in, and why particular decisions 
were made. 

Even existing automated solutions are neither timely nor efficient. 

15 Furthermore, existing automated solutions limit users to a sequential 
processing of procurement documents (e.g. a requisition document must first 
be created, then a solicitation document must next be created, etc.) which 
limits the situations in which existing automated solutions may be applied. 

For example, suppose an important bridge washes out, and gravel 

20 needs to be procured to fix the bridge. The Governor of the state in which the 

bridge is located signs an emergency declaration circumventing the normal 
rules of fair-play and proper vendor selection, and authorizes the state 
government to immediately evaluate bid responses. In this scenario, the 
government's preferred procurement process would circumvent the time 

25 consuming requisition and solicitation stages of the procurement process, and 

would instead jump immediately to the bid response stage to ultimately 
determine the gravel company which can deliver the needed supplies to the 
bridge in the most expedient manner possible. This way, the bridge may be 
repaired in the shortest amount of time possible. Existing automated 

30 solutions are not capable of handling this scenario because of their 

aforementioned sequential nature. 

As a further example, suppose an organization goes through most of 
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the stages of the procurement process (requisition, solicitation, bid response, 
evaluation to choose a vendor, and award) and then the chosen vendor goes 
out of business. The end-user of existing automated procurement systems 
must go back to the beginning stage (requisition) and go through each 
5 procurement stage in turn before a new vendor may be awarded a contract, 
even though it would be more expedient for the end-user to go directly to the 
bid-evaluation stage in order to select a new vendor. 

Additionally, both existing manual and automated solutions create a 
document trail which inevitably becomes unwieldy, due to the number of 

10 documents, decisions, quotes, and other procurement information generated 
during a procurement process. 

Therefore, a need exists for a procurement system that stores all of the 
records, decisions, quotes, and other procurement information generated 
during a procurement process as a single entity, and that allows for an end- 

15 user to jump from one procurement stage to another in a non-sequential 
manner. 

SUMMARY OF THE INVENTION 

20 It is an object of the present invention to store all of the records, 

decisions, quotes, and other procurement information generated during a 

procurement process as a single entity. 

It is another object of the present invention to allow for an end-user to 

jump from one procurement stage to another in a non-sequential manner. 
25 It is a further object of the present invention to redefine what stages 

are required for a particular procurement process. 

It is yet another object of the present invention to have an identifier 

associated with a procurement entity which tracks the procurement entity as it 

goes through various stages and events of a procurement process. 
30 It is another object of the present invention to allow the requesting, 

viewing, and/or modification of a procurement entity by its procurement 

identifier. 
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The above objects can be attained by a computer implemented method 
for facilitating the procurement of goods and services, comprising requesting 
any one of a plurality of procurement entities, completing records and events 
associated with the requested procurement entity, and recording said events. 

5 The present invention treats procurement as a single entity which 

moves through several stages. An end-user may request to work with any 
procurement entity and any record or event associated with any stage of the 
procurement process. Moreover, end-users may modify the names and 
number of the stages to match their particular procurement needs. The 

10 present invention also streamlines the procurement process by removing the 
duplication which existing systems have by storing all of the procurement 
data in a single location. 

These together with other objects and advantages which will be 
subsequently apparent, reside in the details of construction and operation as 

15 more fully hereinafter described and claimed, reference being had to the 

accompanying drawings forming a part hereof, wherein like numerals refer to 
like parts throughout. 

BRIEF DESCRIPTION OF THE DRAWINGS 

20 

Figure 1 shows the stages and sequential flow of a procurement 
process according to the prior art. 

Figure 2 shows a procurement entity database according to the present 
invention. 

25 Figure 3 shows the relationships between a procurement entity and the 

procurement entity data-fields of Figure 2. 

Figure 4 shows the possible different flows of a procurement process 
according to the present invention. 

Figure 5 shows a flowchart representing the creation of a procurement 

30 entity. 

Figure 6 shows a flowchart representing the insertion of additional 
procurement records into an existing procurement entity. 
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Figure 7 shows a flowchart representing copy-forwarding of 
procurement records into an existing procurement entity. 

Figure 8 shows a flowchart representing the modification of existing 
procurement records in a procurement entity. 

5 

DESCRIPTION OF THE PREFERRED EMBODIMENTS 
An embodiment of the present invention treats a procurement as a 
"need" which moves as an entity through various stages and activities before 
it is acquired. A procurement entity is a grouping of data typically but not 
10 limited to initially including requisition information, to which more data 
throughout the procurement process may be added, and upon which decisions 
may be made. The procurement entity may be continually tracked throughout 
the procurement process. 

Figure 2 shows a procurement entity database according to the present 
15 invention. Procurement entity database 40 is composed of several data-fields, 

including procurement records 50, milestones 60, procurement identifier 70, 
procurement states 75, and other information 80, all of which will be 
discussed below. 

Procurement entity 40 is a virtual procurement folder, which allows 
20 procurement administrators to assign various procurement items, including 

records 50 and milestone lists 60, into logical groups. These groups then 
include all the information that is needed to successfully complete a particular 
type of procurement. A procurement type is a user defined sequence of states 
used in the procurement process to buy goods and/or services. There are 
25 several types of procurements, including but not limited to delivery order, 
price agreements, supply agreements, professional services, construction, 
unclassified, and contract procurements. Procurement entity 40 may be 
classified as any type of procurement. 

User-defined rules may be linked to the procurement types. For 
30 example, the rules may include (but are not limited to) which states are valid 
for a particular procurement type, which documents which may be created 
within a particular state, and the default record types for each state. 
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Procurement records 50 are used to gather the information needed for 
the successful completion of a procurement. Procurement records 50 are 
created with specific types of procurements and parts of the procurement 
process in mind. Procurement record types include but are not limited to 
5 Requisition (RQ), Performance Evaluation (PE), Solicitation (SO), Renewal 

(RN), Solicitation Response (SR), Termination (TM), Evaluation (EV), 
Receiver (RC), Master Agreement (MA), Invoice (IN), and Purchase Order 
(PO). 

Each type of procurement has states. States are different stages in the 

10 lifetime of a procurement. Further, each procurement type may have a 
different number and/or combination of states. Procurement states 75 stores 
the procurement states corresponding to the procurement type of a particular 
procurement entity. 

Each stage or state that a procurement passes through requires specific 

15 types of records. For example, the requisition state generally requires RQ 

records, the solicitation state generally requires SO records, the bid response 
state generally requires SR and SO records, the evaluation state generally 
requires EV records, the award state generally requires MA and PO records, 
and the contract management state generally requires IN, RC, PE, TM, and 

20 RN records. Users may define or redefine which records are required per 
state for a given procurement type. 

Procurement records associated with a state collect information which 
is specific for the part of the procurement process that the state represents. 
The records associated with subsequent states build on the records that were 

25 entered in the previous state. Thus, procurement records 50 may contain data 

associated with different procurement states. 

For example, the record associated with the Requisition state collects 
very basic information (including but not limited to the issuer and/or the items 
needed), the record associated with the Solicitation state then takes the 

30 information gathered in the Requisition state and includes the information 
needed to successfully advertise for bids in the open market. Such 
information may include but is not limited to terms and conditions and/or 
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evaluation criteria. The records in the subsequent states further build on the 
information. This information can vary depending on the procurement 
actions that take place. These may include adding vendor responses to bids, 
questions and responses made by vendors, evaluation worksheets, terms and 

5 conditions, and data related to the type of award. 

In addition, procurement entity 40 may also contain any amendment 
information to any item of the procurement, and system related data such as 
record status, types of actions completed, acquired or needed approvals, and 
user notes, stored in data-field other information 80. 

10 Each procurement entity has a unique procurement identifier 70, such 

as a number, icon, or alpha-numeric string. For example, a procurement 
number may be assigned to a group of data to denote the data is part of the 
same procurement entity. The procurement number may be assigned at the 
time a new procurement is created, usually at the requisition, although the 

15 procurement number may be assigned at any state. When a new procurement 

is started the record created is typically the first record in the chain for the 
selected procurement type, which may also be stored in data-field 70. The 
subsequent records that are defined as part of the procurement chain for the 
selected procurement type are created by the user selecting a new record 

20 action in a state viewer for the next state configured as part of the 
procurement chain for the selected procurement type. 

The state viewer allows a user to view and edit all procurement 
records 50 that are associated with a particular procurement identified by 
procurement identifier 70. Records that are specific for a state are grouped in 

25 that states 1 state viewer. Users may move through the various states of 

procurement to view, edit, or create records that are specific to the 
procurement and state. This allows the user to not only view information 
currently on file for a past state of the procurement but the user may create 
records in advance that will be used in future states of the procurement. For 

30 instance, users may begin creating the criteria needed to evaluate bids from 

vendors in the Solicitation State before the associated Requisition record has 
been accepted and finalized. 
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Milestone list items 60 are events that should take place in order for 
the procurement to move through the various stages of the procurement 
process. Milestones provide a checklist of activities that should occur to the 
procurement within each particular state. Users may define which milestones 
5 list items appear in each state for a given procurement type. Milestones may 
be either mandatory or non-mandatory. The rules which determine this are 
user-configurable. Thus, users may configure their milestone list as they see 
fit. 

The purpose of a state is to organize the events and actions that occur 

10 during a procurement as well as manage the components associated with a 

record. The procurement business may generally be divided into six states: 
requisition 5, solicitation 10, bid response 15, evaluation 20, award 25, and 
contract management 30, as shown in Figures 1 and 4. 

Within each state there are numerous actions and milestone list items 

15 which occur. Actions are processes which are applied to procurement records 
within the state. Milestone list items are steps that should be or must be 
completed within a state. Milestone list items are non-system in nature. The 
state tracks which milestone list items have been completed and displays a 
date completed for the item, based on the current system date at the time the 

20 user marks the item completed. Some milestone list items may be mandatory 
while others may not. The milestone list and their associated requirements 
are configurable and may be established by each user. 

Figure 3 shows the relationships between a procurement entity and the 
procurement entity data-fields of Figure 2. Procurement entity 40 has a one- 

25 to-one relationship with procurement identifier 70. That is, procurement 
identifier 70 uniquely identifies a single procurement entity 40. 

Procurement identifier 70 has a one-to-many relationship with 
procurement states 75, procurement records 50, other information 80 
(including procurement notes), and milestones 60. That is, for any individual 

30 procurement identifier 70 (and thus for individual procurement entity 40), 
there are corresponding multiple procurement states, records, notes, and 
milestones. 
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Procurement states 75 has a one-to-many relationship with 
procurement records 50, other information 80 (including procurement notes), 
and procurement milestones 60. That is, for every individual procurement 
state, there are multiple corresponding records, other information (including 

5 notes), and milestones. 

Figure 4 shows the possible different flows of a procurement process 
according to the present invention. At the most basic level, a procurement 
moves from state to state, e.g., from requisition state 5 to solicitation state 10, 
from solicitation state 10, to bid response state 15, from bid response state 15 

10 to evaluation state 20, from evaluation state 20 to award state 25, and from 
award state 25 to contract management state 30. However, it is not necessary 
to complete the states 5, 10, 15, 20, 25, and 30 in sequential order. Instead, 
any state of states 5, 10, 15, 20, 25, and 30 may be an initial state to be 
completed, from which any of the states 5, 10, 15, 20, 25, and 30 (not 

15 including the chosen initial state) may be a next or future state to be 

completed. 

For instance, from requisition state 5, solicitation state 10 may be a 
next state as shown by arrow 190, bid response state 15 may be a next state as 
shown by arrow 90, evaluation state 20 may be a next state as shown by 
20 arrow 100, award state 25 may be a next state as shown by arrow 110, or 

contract management state 30 may be a next state as shown by arrow 120. 

From solicitation state 10, requisition state 5 may be a next state as 
shown by arrow 190, bid response state 15 may be a next state as shown by 
arrow 200, evaluation state 20 may be a next state as shown by arrow 130, 
25 award state 25 may be a next state as shown by arrow 140, or contract 

management state 30 may be a next state as shown by arrow 1 50. 

From bid response state 15, solicitation state 10 may be a next state as 
shown by arrow 200, requisition state 5 may be a next state as shown by 
arrow 90, evaluation state 20 may be a next state as shown by arrow 210, 
30 award state 25 may be a next state as shown by arrow 160, or contract 
management state 30 may be a next state as shown by arrow 170. 

From evaluation state 20, bid response state 15 may be a next state as 
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shown by arrow 210, solicitation state 10 may be a next state as shown by 
arrow 130, requisition state 5 may be a next state as shown by arrow 100, 
award state 25 may be a next state as shown by arrow 220, or contract 
management state 30 may be a next state as shown by arrow 180. 

5 From award state 25, evaluation state 20 may be a next state as shown 

by arrow 220, bid response state 15 may be a next state as shown by arrow 
160, solicitation state 10 may be a next state as shown by arrow 140, 
requisition state 5 may be a next state as shown by arrow 110, or contract 
management state 30 may be a next state as shown by arrow 230. 

10 From contract management state 30, award state 25 may be a next 

state as shown by arrow 230, evaluation state 20 may be a next state as shown 
by arrow 180, bid response state 15 may be a next state as shown by arrow 
170, solicitation state 10 may be a next state as shown by arrow 150, or 
requisition state 5 may be a next state as shown by arrow 120. 

15 Thus, a procurement entity and its associated records and milestones 

can be accessed from within any state so that work can proceed on certain 
activities in future states prior to former states being completed. For example, 
an evaluation scorecard may be prepared in Evaluation state 20 when a 
requisition from requisition state 5 has not yet been accepted. A state is 

20 deemed completed when all mandatory milestone list items have been 
completed and all associated records are in a final state of completion. 

Because the number of states varies from user to user, the present 
invention permits a user to change the number of states from the six listed 
above, to a greater or lesser number of states. Furthermore, the present 

25 invention allows for the automatic changing from one state to another state 
depending upon user-defined variable rules, and further allows for a user to 
rename the states to suit a user's procurement needs. 

Figure 5 shows a flowchart representing the creation of a procurement 
entity. At operation 300, a user is given a choice of selecting a pre-defined 

30 procurement type, or selecting a new procurement type. If the user selects a 
pre-defined procurement type, then a new record is created with a record 
identifier matching the default record identifier associated with the selected 
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procurement type's first state at operation 310, and processing proceeds to 
operation 320. A record identifier is a sub-category within a record type. For 
example, within the record type "Purchase Order", the present invention may 
have record identifiers for "Simple Purchase Order", "Delivery Order", or 

5 "Service Contract". 

If, on the other hand, the user selects to create a new procurement 
type, then a new record is created with a new record identifier at operation 
350, and processing proceeds to operation 360. 

At operation 320, the user is prompted to save the new record of the 

10 selected procurement type. If the user decides not to save the record, then the 
new procurement entity process ends at operation 325. If, on the other hand, 
the user decides to save the record, then a new procurement is created of the 
type chosen by the user at operation 330. 

At operation 360, the user is prompted to save the new record of the 

15 new procurement type. If the user decides not to save the record, then the 
new procurement entity process ends at step 325. If, on the other hand, the 
user decides to save the record, then a new procurement of the new 
procurement type is created at operation 370. 

At operation 340, a new procurement entity is created with a unique 

20 procurement identifier, procurement states are created based upon the 
procurement type chosen by the user, default procurement milestones are 
determined based upon the selected procurement type, or alternately, 
milestones are determined independently by a system administrator for a new 
procurement type, and the new record is inserted into the procurement entity 

25 into its appropriate state, which is typically the selected procurement type's 

first state. The new procurement entity process then terminates at operation 
380. 

Figure 6 shows a flowchart representing the insertion of additional 
procurement records into an existing procurement entity. At step 400, a user 
30 chooses to create a new record within a procurement by a record identifier. 

Operation 410 determines if a record with the selected record identifier is 
allowed within the current procurement entity. If the record is not of a type 
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allowed by the current procurement entity, then the new record is prevented 
from being inserted into the procurement entity at operation 415, where the 
record insertion process ends. If, on the other hand, the record identified by 
the record identifier is allowed within the current procurement entity, then 

5 operation 420 determines the state in which the user selected record belongs. 

Operation 430 determines if the state in which the user selected record 
belongs is able to receive new records. If not, then the record is prevented 
from being inserted into the procurement entity at operation 415, where the 
record insertion process ends. If, on the other hand, the state that the record is 

10 allowed in is able to accept new records, then the record is created at 
operation 440. 

At operation 450, the user is given the option to save the record. If the 
user decides not to save the record, then the record insertion process ends at 
operation 455. If, however, the user elects to save the record, then processing 

15 proceeds to operation 462, which determines if the new record belongs in the 
currently opened state of the procurement entity. If the new record does not 
belong in the currently opened state, then the current state is closed at 
operation 465, the appropriate state that the record belongs in is opened at 
operation 470, and the new record is inserted into the current (and 

20 appropriate) state at operation 475. If, on the other hand, the new record does 
belong in the currently opened state, then processing proceeds from operation 
462 to operation 475, where the new record is inserted into the current (and 
appropriate) state. 

The record insertion process then ends at operation 480. 

25 Figure 7 shows a flowchart representing copy-forwarding of 

procurement records into an existing procurement entity. Many records have 
other records which logically follow after them in the procurement process. 
For example, a purchase order record may immediately follow a requisition 
record, because a buyer may be ready to buy the items which were 

30 requisitioned. In the copy-forwarding process, a new record is created by 
pushing information forward from one record (e.g. a requisition record) to a 
record which logically follows the one record (e.g. a purchase order record). 
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At step 500, a user selects an existing record within a procurement 
entity by its record identifier. The record is opened, data from the selected 
record is copied into a newly created record, and the user then selects a 
destination record identifier for the newly created record. Operation 410 
5 determines if a record with the selected record identifier is allowed within the 
current procurement entity. If the record is not of a type allowed by the 
current procurement entity, then the new record is prevented from being 
inserted into the procurement entity at step 415, where the copy- forwarding 
process ends. If, on the other hand, the record identified by the record 

10 identifier is allowed within the current procurement entity, then operation 420 
determines the state in which the user selected record belongs. 

Operation 430 determines if the state in which the user selected record 
belongs is able to receive new records. If not, then the record is prevented 
from being inserted into the procurement entity at operation 415, where the 

15 copy-forwarding process ends. If, on the other hand, the state that the record 
is allowed in is able to accept new records, then the record is created at 
operation 440. 

At operation 450, the user is given the option to save the record. If the 
user decides not to save the record, then the copy-forwarding process ends at 

20 operation 455. If, however, the user elects to save the record, then processing 

proceeds to operation 462, which determines if the new record belongs in the 
currently opened state of the procurement entity. If the new record does not 
belong in the currently opened state, then the current state is closed at 
operation 465, the appropriate state that the record belongs in is opened at 

25 operation 470, and the new record is inserted into the current (and 

appropriate) state at operation 475. If, on the other hand, the new record does 
belong in the currently opened state, then processing proceeds from operation 
462 to operation 475, where the new record is inserted into the current state. 
The copy-forwarding process then ends at operation 480. 

30 Figure 8 shows a flowchart representing the modification of existing 

procurement records in a procurement entity. A user may wish to modify an 
existing procurement record for any number of reasons, for example, to add 
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additional information to the record, to correct errors, or to delete information 
from the record. 

At operation 600, a user selects an existing record within a 
procurement entity to modify by its record identifier. The user may then 
5 modify the record at operation 610. 

At operation 450, the user is given the option to save the record. If the 
user decides not to save the record, then the record modification process ends 
at operation 455. If, however, the user elects to save the record, then the 
modified record is inserted into its determined state within the procurement 
10 entity at operation 460, and the record modification process ends at operation 

490. 

The many features and advantages of the invention are apparent from 
the detailed specification and, thus, it is intended by the appended claims to 
cover all such features and advantages of the invention which fall within the 
15 true spirit and scope of the invention. Further, since numerous modifications 

and changes will readily occur to those skilled in the art, it is not desired to 
limit the invention to the exact construction and operation illustrated and 
described, and accordingly all suitable modifications and equivalents may be 
resorted to, falling within the scope of the invention. 



